feat(go): add Go bindings via cgo - #454

Adds a Go binding to pdf-inspector alongside the existing Node.js and
Python bindings, following the same "one small ABI, mirror the core
crate" pattern as napi/src/lib.rs — but via a hand-written C ABI +
cgo instead of napi's marshaling, since Go has no napi/PyO3 equivalent.

go/ is a new Rust crate (cdylib + staticlib) exposing exactly two
functions plus a matching free: pdfinspector_classify,
pdfinspector_extract_text, pdfinspector_free_string. Each returns an
owned JSON envelope ({"ok":true,"result":...} / {"ok":false,"error":...})
rather than a marshaled struct, since plain C has no object-marshaling
story — this keeps the ABI to three functions with no struct layout to
keep in sync across languages. Every entry point wraps its body in
catch_unwind, mirroring napi's catch_panic, since a Rust panic
unwinding across the FFI boundary is undefined behavior.

go/pdfinspector is the Go package: cgo bindings over that ABI, with
${SRCDIR}-relative CFLAGS/LDFLAGS so `go test` works with no env vars
once the Rust library is built once via `cargo build --release` in go/.

Scope is deliberately v1: Classify and ExtractText only (the two
operations an OCR-routing pipeline needs), not the Node binding's
fuller surface (markdown/process_pdf, region/table extraction, vector
grid detection). Extending go/src/lib.rs with the same envelope
pattern is the natural follow-up if there's interest.

Tested against tests/fixtures (text-based classification + extraction,
encrypted-PDF and invalid-input error handling). cargo fmt/clippy clean.

Co-authored-by: Cursor <cursoragent@cursor.com>

…bustness)

Two P1 correctness bugs, both documentation-vs-implementation
mismatches rather than behavioral bugs (verified via new regression
tests that the implementations already matched Node/Python's real,
tested behavior — only my doc comments were wrong):

- ProcessPdf's `pages` doc claimed 0-indexed; the core PdfOptions::pages
  it forwards to is 1-indexed, matching Python's own documented
  `process_pdf(path, pages=[1, 3, 5])` and napi's untested-but-identical
  passthrough. Fixed docs to 1-indexed everywhere (lib.rs, header,
  pdfinspector.go, params.rs); added a cross-check test against
  ExtractPagesMarkdown (definitively 0-indexed) proving physical-page
  alignment, not just self-consistency.
- ExtractTextWithPositions's `pages` doc had the same issue — 1-indexed
  in reality, matching the TextItem.Page field the results carry and
  napi's own tested behavior. Same doc fix + a test that filtering by
  pages=[1] returns exactly as many items as unfiltered items report
  Page==1 (catches an off-by-one a naive "same page number comes back"
  check wouldn't).

Other fixes:
- pagesParams.Pages / OcrOptions.PageNumbers: removed `omitempty` — it
  collapsed a Go caller's explicit empty (non-nil) page selection and a
  nil one to the same "field omitted" JSON, losing the "process zero
  pages" case entirely. Added a regression test.
- publish-go.yml: workflow-wide `contents: write` narrowed to `read`,
  scoped `write` to only the release job that actually needs it; fixed
  the version-change check dying on the very first push that introduces
  go/Cargo.toml (no parent-commit manifest to diff against).
- fetchnative: musl-Linux hosts now refuse the (glibc-only) prebuilt
  download instead of fetching a library that won't load; alreadyBuilt
  checks only the host's own library extension instead of either
  platform's (a stale cross-platform artifact no longer produces a
  false "already built"); extraction now goes through a temp dir so a
  mid-extraction failure can't leave a partial file that future runs
  mistake for a complete one; releaseVersion now reads go/Cargo.toml
  directly instead of duplicating it as a hand-synced literal. Added
  tests for the failure-cleanup and version-reading behavior.
- ci.yml's ocr-runtime job now also builds the Go native library and
  runs a real PDFium+ONNX Runtime OCR pass (TestProcessPdfWithOcr_
  AutoMode_ScannedFixture, skipped outside that job) — previously the
  `go` job built with the `ocr` feature but only ever exercised OcrOff/
  Auto-on-clean-text-PDF, so a regression in the actual OCR dynamic-
  loading path would have gone undetected.
- Doc-only: go/README.md's "two operations" -> "three" (Classify,
  ExtractText, DetectPdf all take no options); Makefile's stale
  `gen.go` reference -> the real path; params.rs's PagesParams doc now
  spells out the per-function indexing instead of a blanket (and, per
  the above, partly wrong) "0-indexed" claim; pdf_inspector.h's
  vector-grid doc now notes its three fields are required, not
  optional-with-defaults.

Co-authored-by: Cursor <cursoragent@cursor.com>

…leness)

- README: clarify libpdf_inspector_go.{so,a}/.{dylib,a} artifact sets are
  platform-specific, not a single build's output.
- fetchnative: track which release a fetched library came from via a
  .fetchnative-release.json marker, so a version bump in go/Cargo.toml is
  no longer silently ignored by an already-present library (locally-built
  libraries with no marker are still always trusted, unchanged).
- fetchnative tests: extract the post-extraction "was the expected
  library actually part of this download" check into libraryWasInstalled
  so the stale-library regression test exercises the real code path
  main() uses instead of a parallel hand-rolled assertion; add matching
  positive-case and marker-staleness tests.

Co-authored-by: Cursor <cursoragent@cursor.com>

Its pages argument is 0-indexed, but PagesNeedingOCR/PagesWithTables/
PagesWithColumns on the returned PagesExtractionResult are 1-indexed
(matching the struct's own field comments) -- the indexing summary
grouped the whole function under "0-indexed" without carving out this
exception the way it already does for DetectPdf/ProcessPdf and Classify.

Co-authored-by: Cursor <cursoragent@cursor.com>